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(57) ABSTRACT 

A method for transferring a data packet from a compressor 
to a decompressor said data packet including a header with 
header data fields. A number of the header data fields that 
remain constant during the data transfer are stored in the 
decompressor. In a compressed data packet, a header data 
field that varies is replaced by a compressed value identi- 
fying a data packet in a compression sequence. In the 
decompressor context data comprising information for relat- 
ing the received compressed value to a corresponding com- 
pression sequence is maintained and the information is 
updated according to the received compressed values. The 
compressed value and the information of the corresponding 
compression sequence are used for mapping the compressed 
value into a decompressed header data field. Thus com- 
pressed data is unambiguously mapped to a full packet data 
header field in the decompressor side throughout the session. 

17 Claims, 8 Drawing Sheets 
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HEADER COMPRESSION IN REAL TIME until a regularly transmitted uncompressed header (refresh 

SERVICE header) is received. This means that after a transmission 

error all packets until the next refresh packet are lost. In 
transmission links where errors occur relatively seldom this 

FIELD OF THE INVENTION s does not have much effect on the transmission throughput. 

The present invention relates to data transmission and Anyhow, when a link with high risk of multiple transmission 

especially to a method for transferring a data packet from a ^ * ™l ' ! * dlsru P tlve * ^ 15 es P ecialI y 

compressor to a decompressor, said data packet including a thc casc w,th wirclcss transmissions, 

header with header data fields, a number of the header data A publication "Low-loss TCP/IP header compression for 

fields that remain constant during the data transfer being 10 wireless networks'^ by Mikael Degermark, Mathias Engan, 

stored in the decompressor. The method comprises sending Bjorn Nordgren and Stephen Pink, Wireless Networks 3 

from the compressor and receiving at the decompressor a (1997) 375-387, J. C. Balzer A G, Science Publishers 

data packet comprising information on one or more header presents header compression schemes for UDP/IP and TCP/ 

data fields that vary during the data transfer; and decom- IP protocol where the problem of simplex links and lossy 

pressing the header using the stored header data fields and :5 links have been dealt with. In the presented system the 

the received information on the one or more header data compressor sends a full header and a compression identifier, 

fields that vary during the data transfer. The invention also which is a small unique number also carried by compressed 

relates to access network elements implementing the headers. The full header is stored as a compression state by 

invented method. the decompressor. The compression identifiers in com- 

20 pressed headers are used to lookup the appropriate compres- 

BACKGROUND OF THE INVENTION sion state to use for decompression. To avoid incorrect 

Real time services constitute an emerging set of technolo- decompression due to inconsistent compression state some 

gies that enable voice, data and video collaboration over farther mechanisms are introduced Each version of the 

packet switched networks. Along the standardisation of « compression state is associated with a generation, repre- 

packet switched radio systems interest in providing real time rented by a number, carried by full headers that install or 

services also through wireless networks has risen. In real refresh lhat compression state and in headers that were 

time services packet transmission is carried out using a compressed using it Thus the decompressor is able to detect 

number of protocols. This introduces a large protocol over- when lts compression state is out of date by comparing its 

head and causes inefficient bandwidth usage. As the trans- 30 generation t0 the generation in compressed headers, 

mission rates in wireless systems are limited, transferring of ^^rmore, to avoid long periods of packet discard when 

large headers mean wasteful use of capacity. M hcadcrs arc lost and °* the _ other hand t0 g et as hl S h 

^ , , i r i , i r compression rates as possible, the compressor starts with a 

To overcome the problem of large headers a variety of ^ in , erval betweeQ m ^ ^ ^ refresh 

header compression schemes have been introduced. Pubh- . «• n • a u r i_ . i 

ar > in /t tt*sti ititd rr j e t o is exponentially increased with each refresh until a steady 

cation Compressing IP/UDP/RTP Headers for Low-Speed 35 « + e m u • a • u a / ■ 1 * *\ a 

o - , t 1 » . r> ^ 1 1 7 t . T - state refresh period is reached (compression slow-start). A 

Serial Links by S. Casner and V. Jacobson, Internet Enei- a * * a cc c uj ■ 1 

>-p t £ ixrrcDKrcTnn AC t a , modest trade-off of some header compression is also sug- 

neering Task Force, INTERNET-DRAFT, draft-ietf-avt- ffe o te H 

crtp-05.txt, July 1998 presents effective header compression 

algorithms that enable header size reduction by a magnitude. Thou g h the ^ of compression slate generation facilitates 
The presented header compression is based on the fact that 40 ca5ie r detection of inconsistent compression states, the pack- 
some of the bytes in the IP, UDP and RTP headers remain ets Wl11 an y how be losl unUl a header installs a P ro P er 
constant over the life of the connection. After sending an compression state. Compression slow-start helps finding a 
uncompressed header these fields may be elided from the convenient trade-off between the compression rate and 
compressed headers that follow. Furthermore, differential acceptable recovery time, but in difficult transmission 
coding is used on the changing fields to reduce their size. In 45 condltlons > the compression rate will anyhow be compro- 
RTP header the difference from packet to packet is often mised and the ^vantage of header compression will be 
constant and therefore also the second order difference is diminish. 

zero. By maintaining both the uncompressed header and the SUMMARY OF THE INVENTION 

first order differences in the session state shared between the 

compressor and decompressor, it is mainly necessary to 50 Now a method and network elements implementing the 
indicate that the second order difference between successive method have been invented, with the help of which these 
packets is zero. It is also suggested that a compressor problems can be avoided or their effect can be reduced, 
implementation might maintain state for multiple session According to a first aspect of the present invention there 
contexts. Using a hash function on certain predefined fields ^ provided a method for transferring a data packet from a 
to index a table of stored session contexts, and including a 55 compressor to a decompressor said data packet including a 
session context identifier in compressed packets would header with header data fields, a number of the header data 
enable the decompressor to index a table of stored session fields that remain constant during the data transfer being 
contexts directly. stored in the decompressor. The method comprises sending 
Real time services cause strict limits for transmission from the compressor and receiving at the decompressor a 
delays and therefore normal retransmission procedures (e.g. 60 data packet comprising information on one or more header 
in Transport Control Protocol, TCP generally used for trans- data fields that vary during the data transfer; decompressing 
mission of IP packets) are generally not applicable. Thus, a the header using the stored header data fields and the 
link in real time services in practice will be considered a received information on the one or more header data fields 
simplex link. In the prior art reference, for simplex links a that vary during the data transfer. The method is character- 
periodic refresh scheme is suggested. Whenever the decom- 65 ised by sending from the compressor and receiving at the 
pressor detects an error in a packet stream, it discards all decompressor a compressed value for a header data field, 
packets in that stream, and will not resume decompression said compressed value identifying the data packet in a 
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compression sequence; maintaining in the decompressor FIG. 8 illustrates the format of a SND CP SN-UNITD ATA 

context data comprising information for relating the PDU; 

received compressed value to a corresponding compression FIG. 9 illustrates an alternative embodiment; and 

sequence, the information being updated according to the FIG. 10 illustrates blocks responsible for different func- 
received compressed values; and using the compressed s lions in a mobile slaUo n accordLg to the invention, 
value and the miormation oi the corresponding compression 

sequence for mapping the compressed value into a decom- DETAILED DESCRIPTION OF THE DRAWINGS 
pressed header data field. 

-n_ , , f4 , . , ,r t T" e invention will be illustrated with an embodiment 

The advantage of the invention b based on the fact that where an ITU . T voicc 6ncoder Q>mi Inteme , PcQlocol 

most of the fields in the network layer packet remun w ver sion 4 and General Packet Radio System (GPRS) of ETSI 

constant throughout a session Ne work layer in tbis context are in each of thcse u ^ to v a ^ &med 

^tot^^t^l^pt^l^nhtnai in the art „ be noted ^ for M ^ g 

to e.g. P UDP and RTP protocol^ Furthermore, it .s paraJle , or corresponding techrjologies exist and will £ urther 

appreciated mat cnanges in tne news tnat vary trom packet evolve _ consequently, the scope of prote, stion is not limited 

to packet are predictable. Such fields are sent m a com- H b y the details of the protocols used in the following descrip- 

pressed form to the decompressor. Based on the prior ^ ^ method ted herein fa a ]icaWe £ . fi £ 

knowledge of the anticipated changes the decompressor nelWQrks bu , , he Wem bej more ^ btrusive in wireless 

w,ll generate and maintain context data that .s updated with communicatiori) ^ a stnlctur * fa ^ in mis e ]e . 
the information from the packets that are received in the rT „ - . . . 

decompressor. Compressed data maps unambiguously to a 20 ^ pre f DtS the accumulat . lon °/ header overhead by 

change in a decompressed value in a set of consecutive data the dlfferen 1 t ^ m Emission of one voice frame 10 

packets, a compression sequence In the context data, infor- ^ a Wir f s ? ? connection. ™ e shaded blocks represent 

mation on one or more compression sequences is main- ^ ader u S and wh * e ^ocks represent payload in a data frame, 

tained. This information provides means for associating the £ irst ih * framc ™ 15 encapsulated into a Real Time 

received compressed data with a correct compression 25 £ rotoco S ? ut " t0 a Us n er Data 

sequence. Using the received compressed data with the Protocol (UDP) packet 12 and further to an Internet Protocol 
corresponding context data maintained in the decompressor pa f ? l A 3 ' ™* Pack f 13 if furlher encapsulated 
enables the compressed data to be unambiguously mapped !f ■ ? ??\ Co 1 nver S cn ^ e /T ? ™!° Qo] 

to a full packet data header field in the decompressor side < SN ° C n P > | 4 ^g^al Link Control protocol (LLC) into 

throughout the session. Preferably, data packets carrying 30 an LLC block 15, which is divided into an appropriate 

information that can not be correctly associated with any of nun * er of RL L C blocks , each conta _ inin S a separate header. As 

the compression sequences of the context data maintained in canbe ^ * c cumulat ^ e ove [ head f 5 very large. Already 

the decompressor are filtered out already in the compressor m IP .^[? r * e P rotoco1 J^*?"* 15 4 ° * yt f s and the 

side. Compared to the earlier solutions, the compression in ba * d ™ dth ulilization around 33% when a G723.1 encoder is 

the invented method is increased since also the varying 35 used. Sinc^ still more overhead is generated by the protocol 

fields that are related to identification of packets can be headerS of the Wireless hnk > the Sltuatl0n § ets even worse ' 
compressed. Still, transmission errors will have effect only In tbls embodiment, header compression and header 

on transmission of individual packets and problems in decompression are carried out in the protocol layer specific 

transmission of one packet do not escalate to subsequent !° the access network > ™ this case the SNDCP layer. FIG. 2 

packets. The scheme of refreshing complete header infor- 40 illustrates some of the functional elements and the related 

mation can be designed to occur at longer intervals, or it can protocol structures of a GPRS network. GPRS is imple- 

be abandoned altogether. Further aspects of the invention are mented logically to general GSM-struture by two network 

presented in the independent claims 9, 13 and 15. Preferred elements, a Gateway GPRS Support Node (GGSN) and a 

embodiments are presented in the dependent claims. Serving GPRS Support Node (SGSN). GGSN is the first 

45 Packet Data Network access point in a GSM network 

BRIEF DESCRIPTION OF THE DRAWINGS supporting GPRS. Data packets whose PDP Address (Packet 

Data Protocol, e.g. IP or X.25) indicate a GPRS-subscriber 

For a better understanding of the present invention and in are rou ted to the GGSN. GGSN provides information 

order to show how the same may be carried into effect needed to route the data packets to the subscriber's current 

reference will now be made, by way of example, to the 50 access node SGSN. GGSN may query subscriber's location 

accompanying drawings, in which: d ata from a GSM Home Location Register (HLR). SGSN is 

FIG. 1 presents the accumulation of header overhead by an access node serving the Mobile Station (MS). For GPRS 

the different layers in transmission of one voice frame 10 connection, SGSN establishes mobility management func- 

over a wireless IP connection; tionality towards the MS and PDP functionality towards the 

FIG. 2 illustrates some of the functional elements and the 55 packet data network to route the data packets towards 

related protocol structures of a GPRS network; GGSN. SGSN and GGSN can be integrated into a same 

FIG. 3 illustrates fields of the network layer RTP, UDP Physical node, or they may be located in separate nodes, 
and IP headers; Th c access network SNDC function provides to the 

FIG. 4 illustrates functions in the receiving entity accord- n f™ rk la Y er a s ^ tra ^rring a minirnum amount 

ing to the invention* 60 of data betwcen the SGSN and MS through different com- 

^„ , ' , ... , press ion techniques. GPRS provides a procedure, which is 

FIG. 5 represents a format for a compressed header used irnplcmented in conne ction with the service negotiation, for 

m an embodiment of the invention; tne MS and tne SGSN tQ agfee Qn ^ compression algorithm 

FIG. 6 illustrates steps of the embodiment of the invented to be used in the session. In the invented method, parts of the 

method where the abbreviated time-stamp is used; 65 header that are supposed to remain constant are stored in the 

FIG. 7 presents an example of a filtering algorithm SNDCP entities. Next the structure and contents of a net- 
according to the invention; work layer protocol header is studied in more detail. 
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In FIG. 3, fields of the network layer RTF, UDP and IP fields: 310, 311, 312, 313, 315, 318, 321, 322, 331, 332, ,33, 

headers are shown. Considering the RTP, field 310 indicates 334, 335, 336, 337, 338, 339, 341, 342, 343. These fields 

the RTP version in use and docs not change during the will constitute a state of compression that will be maintained 

session. Field 311 includes the padding bit and does not at i east ; n the receiving (decompression) end of the link, 

change unless additional padding is included in the end of 5 ^ mcntioned earli to the no-change fields, a 

tne neaaer ror example or encrypuon atgontnm purposes second 

set of fields whose contents can be deduced from the 

on application layer. Field 312 indicates whether a fixed * j • r . i j 

header is followed by header extension, and will not change [ ccc j vcd in f°™T°» Ca " * e clldcd I n * hc ""P"*"* 

during the session. Field 313 corresponds to CSRC count header Such m * s do n L ot * ave an y effect on the state of 

that is needed for multiplexing purposes e.g. to indicate how in compression either. Such fields in the presented embodi- 

many users have contributed to the payload. In many cases 10 ™ nt * ar f fields 324 and ^ comprising the checksums used 

this value will remain constant throughout the session. Field fo ' ^ e ™ hdltv of thc P ackc *- ™ ese sums be 

315 indicates the payload type and is constant for one type f plated in the decompressor from the decompressed data 

of data. Generally, the contributing source and synchroni- f J elds - ™ e validity of the packets can be ascertained using 

sation source are constant throughout the transmission over J5 J e checks ™s of the 1° W£ * lev el, e.g. access network level 

the air interface, and therefore the field 318 will remain ala umts - 

constant. The solution according to the invention for managing the 

Field 314 includes a marker bit that is optionally used to flelds that change for each packet is illustrated in a general 

mark important events in the packet stream, for instance, the form in Fia 4 ' where factions in the receiving entity, in 

beginning of a speech burst, or a last packet in a video frame. 20 this embodiment the SGSN (also: decompressor) are shown. 

If the marker bit 314 is used it needs to be transmitted in the In connection with the session set-up information needed for 

compressed header. Field 316 indicating the sequence num- the state of compression is received in the decompressor 

ber and field 317 indicating the time stamp will change for ( e -S- a fu ^ header). In order to ensure that a correct state of 

all RTP Packets. compression is used, an acknowledgement procedure can be 

Considering the UDP, field 321 indicating the source port 25 ^eluded in the session set-up signalling. In step 40 the state 

number and field 322 indicating a destination port number of compression SoC is stored m the decompressor. In step 41 

are used to separate different data streams associated to the a s&sslon conlext comprising one or more context values Cj , 

same application. For instance, data and control information each relatin S t0 a certain compression sequence, are initiated 

of RTP layer can be directed to different ports, i.e. different in me decompressor. A packet is received from the trans- 

payload types can use different UDP port pairs. These fields 30 m \ ttirj g entltv > in this case the MS (^o: compressor) (step 

will remain constant as long as same type of data is being 42 >" ^ P acket com pnses a compressed data field Dcom. In 

transmitted. Field 323 indicating the UDP packet length case more than one c ° ntext vahies are maintained 

remains constant as long as the length of the RTP packet (maximum value for j>l), a set of decision rules Dm for 

inside it will remain constant. In cases where the UDP length relatin S a rec eived Dcom with a corresponding context value 

is variable throughout the session (e.g. transmission of 35 Q is defined. A decision rule Dm matching with the received 

video) the length of the packet must be transmitted in the Dc ° m . ls dete ™ined (step 43), and the decompressed value 

compressed header. Field 324 corresponds to the UDP Dfuli 15 denved ( ste P 44 > from the value of the received 

checksum and is used to detect the errors in the transmission. IDcom aQd tne context value Cm of the determined Dm. 

This field does not have to be transmitted over the trans- According to the anticipated evolution of the fields, none, 

mission link that has a strong error protection mechanism or , 0 one or more context values Cm are u P dated < ste P 45 > to 

means to detect transmission errors (e.g. lower protocol maintain the context data. This procedure will be followed 

layer checksums). In this embodiment the SNDCP decom- for new P ackets t hrou ghout the data transfer session, 

pression function can e.g. calculate the checksum from the The changing fields to be transmitted in this embodiment 

decompressed fields and use the calculated checksum in the are field 316 indicating the RTP sequence number, field 317 

decompressed packet. 45 indicating the RTP timestamp and field 335 indicating the IP 

Considering IP, field 331 indicating IP version, field 332 identification. Appreciating the fact that the increments in 

indicating the header length, field 333 indicating the type of thcse ficlds generally remain constant throughout the 

service, field 334 indicating total length of the packetare session, a prior art delta-coding (with reference to a previ- 

assumed to remain constant at least as long as speech frames ousl y transmitted packet) scheme could be suggested, 

encoded at constant bit-rate are transmitted. Field 336 indi- so A^ 110 ^ to avoid the problems presented earlier, an inde- 

cating the flags can be assumed to remain constant as long pendent identification is provided for each network layer 

as the fragmentation s not used. Field 337 including the P acket subject to the compression. 

13 -bit fragment offset is assumed to remain constant as well In the first embodiment, header fields are compressed into 
as field 339 indicating the protocol. Fields 338 indicating the abbreviated fields and transmitted over the link. The length 
time to live and 340 indicating the checksum can be defined 55 of an abbreviated field is chosen to provide transmission of 
by the SNDCP function. During data transmission IP source information that facilitates a correct identification of the 
and destination will remain constant and thus fields 341 and packet during a compression sequence, an interval that is 
342 indicating the source IF address and destination IP generally shorter than the session. Short-term identification, 
address respectively are assumed to remain constant. The provided by the abbreviated fields, combined to a longer- 
identification field 335 is mainly used for IP packet frag- 60 term context maintained in the decompressor provides a 
mentation. If fragmentation is not used, it is not necessary to consistent identification of packets throughout the data 
send this field. If fragmentation is used, SNDCP should first transfer session, and thus enables unambiguous mapping of 
rebuild the packet before compressing it. compressed header fields to full header fields throughout a 

The fields that are assumed to remain constant most of the whole data transfer session, 

time are grouped to a set of no-change fields. In this 65 As an example of such an arrangement, a case of an 

embodiment and in connection with speech frames from a abbreviated time-stamp is presented. FIG. 5 represents a 

constant bit-rate encoder, the set will comprise following format for a compressed header used in this embodiment. 
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Field 51 indicates the type T of the compressed packet. If is greater than A. This being the case, the abbreviated 

T-0, the last octet 56 is not included and the last six bits 53 time-stamp comprising the 16 least significant bits of the 

of the first octet are set to zero, used for some other purpose, time-stamp has reached the maximum, wrapped around and 

e.g. for CRC check, or used for an abbreviated time-stamp. the stored value TSmem2 has to be incremented to the next 

If T»l the compressed header shall include the length octet $ possible value (step 67). After this the time-stamp can be 

and the bits 53 and the last octet 56 are used to indicate the reconstructed and tie stored value TSmeml can be updated 

length of the RTP pay load. This length information is needed as explained with steps 64 and 65. For instance, consider a 

with bit streams where the packet length may vary, e.g. case where the stored time-stamp values are TSmeml =FF 

video bit-streams. Field 52 indicates the marker bit of the FF (hex), TSmem2-02 FF (hex), A-OFFF (hex) and the 

RTP header as explained earlier. The abbreviated time-stamp received abbreviated time-stamp value is TSabb=00 OA 

in this embodiment is a 16-bit field that indicates the 16 least (h ex ). Now the abbreviated time-stamp value 00 OA is 

significant bits of the RTP time-stamp. The context data smaller stored time-stamp value FF FF, the difference is 

comprises the 1 6 most significant bits of the RTP time-stamp grcater than A and therefore the 16 most significant bits 02 

and will be maintained at least in the decompressor end of pp 0 f TSmem2 must be updated by one to a value 03 00. Tne 

tnelink^ resulting timestamp value will thus be 03 00 00 OA. If the 

The flow chart of FIG. 6 illustrates the steps of the difference 

is smaller than A,it means that the packet belongs 

embodiment of the mvenled me hod where the abbreviated , 0 ^ mtKatseqwace> but it arrives del d . In ^ a case 

time-stamp is used. In step 61 the state of compression is .... . , 4 . . • iL ,^ 

received, as in this case in a full timestamp TSfuU received the V* a' T S ^ 

in the beginning of a session. In the beginning of the session significant bits stored in the value T^rnem2 and combining 

the context data is initialised, in this case TSmeml com- 20 lh * t0 the abbreviated time-stamp TSabb received from the 

prising the 16 least significant bits of the original time-stamp compressor. Since this is not the largest abbreviated time- 

and TSmem2 comprising the 16 most significant bits of the stam P received so far, the value TSmeml is not updated. As 

original time-stamp (step 62). In step 63 a new abbreviated lon S ^ more new packets arrive this procedure will be 

time -stamp TSabb carrying 16 least significant bits of the followed. This same idea is applicable for other fields as 

time -stamp of a new compressed network layer data packet 2 S wel1 * For exam P le lel ^ examine a complete sequence 

is received. The new abbreviated time -stamp is compared number of the RTP header. If the original sequence numbers 

with the stored value TSmeml in the decompressor. As will are (in binary form) 00010000, 00010001, 00010010, the 

be seen later, the value of TSmeml will comprise the 16 abbreviated sequence numbers that are transmitted to the 

least significant bits of the largest time-stamp received so decompressor are 0000, 0001, 0010. In the decompressor 

far. 30 context data comprising at least the current most significant 

If the new abbreviated time-stamp TSabb is greater than bits is maintained. With similar type of decision rules the 

the stored value TSmeml, it is further checked whether the compressed data can be associated with the compression 

new abbreviated time-stamp TSabb is greater than the sura sequence(s) in the decompressor and mapped to a full header 

of the stored value TSmeml and a pre-defined value A. The field- 

value A represents a maximum change in the least significant 35 Other type of relation between the compressed data and 

bits that can be interpreted to be caused by some anticipated increments used in the decompressor is possible, as well. For 

phenomena such as silence, lost packets or packets arriving example, when it is known that the time stamp can change 

in slightly wrong order. When the number represented by the by 240 for each packet, an increment of one in the com- 

16 least significant bits of the time-stamp has reached the pressor can be mapped to an increment of 240 in the 

maximum, it will reset and start again from the smallest 40 decompressor. Therein (compression value -^decompressed 

value (compression sequence). When a packet comes late to time-stamp): 0001 -»240 0010-*480 0011-*720 

the compressor, it is possible, that the stored value TSmeml 01 00-* 960, etc. 

has already wrapped around and thus the value of the As shown, the context data is updated according to the 

received abbreviated time-stamp TSabb is considerably information in the received abbreviated fields. The degree of 

larger than TSmeml. By defining an appropriate value for A, 45 abbreviation i.e. the amount of bits used for representing the 

such cases can be detected in the stream of received packets. abbreviated field have an effect on the rate at which the 

If the received abbreviated time-stamp TSabb is greater than context information in the decompressor is updated. For 

TSmeml but the difference is not too big (smaller than A), example, the shorter the compression sequence is the more 

the time-stamp can be reconstructed by using the 16 most often the time -stamp value TSmem2 storing the most sig- 

significant bits stored in the value TSmem2 and combining 50 nificant bits of the time -stamp has to be updated. Even if 

this to the 16 least significant bits received from the com- some packets may be lost or their order may slightly change, 

pressor (step 64). The received abbreviated time-stamp comparisons for validity shown earlier take care that the data 

TSabb is the largest abbreviated time -stamp received so far, can be regenerated correctly. In wireless connections, losing 

and it is thus stored as TSmeml. If the received abbreviated a long sequence of packets generally leads to a dropping of 

time -stamp TSabb is greater than TSmeml and the differ- 55 the ongoing call. Thus as long as the connection can be 

ence is bigger than A, it is assumed that Tsabb arrived late maintained, it is also possible to maintain a consistent 

and Tsmeml has already wrapped around. For these cases, context information in the decompressor with a reasonable 

a further context data value TSmem3 relating to the previous amount of degree of compression. For example, with 6 bits 

compression sequence is maintained in the context data. it is possible to distinguish 64 packets. Losing of 64 suc- 

TSmem3 comprises the previously stored value of TSmem2. 60 cessive packets and still maintaining the connection is 

The reconstruction of the time-stamp is now done by using improbable and therefore the invented method will perform 

the 16 most significant bits stored in the value TSmem3 and well as long as the connection can be maintained, 

combining this to the 16 least significant bits received from For packets that might disturb the compression, e.g. ones 

the compressor. No updates to the values of TSmeml, that arrive very late to the compressor and might therefore 

TSmem2, TSmem3 are made. 65 potentially disrupt the order of updating the compression 

If the value of the received abbreviated time-stamp TSabb information, a farther functionality in the compressor is 

is smaller than TSmeml it is checked whether the difference preferably provided. Receiving a delayed packet where the 
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field to be abbreviated is detected to pose a risk of causing 
an error in the compression information will result in a 
corrective action already in the compressor side. For 
example such packets may be discarded altogether. For 
instance packets arriving late but belonging to the precedent 5 
compression sequence can be recovered the use of context 
value TSmem3, as explained in connection with FIG. 6. A 
packet belonging to a compression sequence preceding the 
precedent compression sequence would not be regenerated 
correctly anymore and therefore such packets are preferen- 10 
tially managed already in the compressor. The flow chart of 
FIG. 7 presents an example of such a filtering algorithm that 
can be added to the invented method in the compressor side 
for managing situations with much delayed packets. 

In step 71 the whole time-stamp of the first received 55 
packet is stored. When a new packet is received (step 72) its 
time -stamp TSnew is read (step 73) and the difference D 
between the stored time -stamp TS and the new time -stamp 
TSnew is calculated (step 74). If the difference D is greater 
than a certain pre-defined value Dm ax, the compressor will 2 o 
deem the packet too much delayed and initiate a corrective 
action (step 75). Such an action is, for example sending 
whole fields instead of abbreviated fields, and including an 
indication to the decompressor not to update of the context 
data. Such an action is also be simply discarding such 2 5 
delayed packets. This would be a natural action in connec- 
tion with real time data packets, since packets that arrive 
very late are in any case useless for the applications and 
therefore they can be discarded already in the compressor 
side. If the difference D is not greater than Dmax, the 30 
time -stamp TS is compressed according to the invented 
method. If the difference is greater than zero, it means that 
the packet has arrived slightly delayed. Preferably the stored 
value TS represents the largest value of the time-stamp 
transmitted so far, and therefore the value of the stored 35 
time -stamp is not updated. If the difference D is smaller than 
zero, the value of the stored time-stamp is updated (step 77). 
This precedure will be followed for each packet throughout 
the session. 

In some cases the identification data can be compressed to 40 
a minimum in the compressed header and still the compres- 
sion sequence will span the whole session. Such an embodi- 
ment comprises a mapping between fields of network layer 
and access network layer protocols. Network layer in this 
context refers to packet data network level protocol layers, 45 
referring to IP, UDP and RTP protocols in the embodiment 
shown herein. Access network layer in this context refers to 
the protocol layer specific to the access network and respon- 
sible for compression and decompression functions, in this 
case the SNDCP. A Packet Data Unit (PDU) of SNDCP 50 
contains an integral number of octets, a header part and a 
data part. Two different SN-PDU formats are defined, 
SN-DATA PDU for acknowledged data transfer and 
SN-UNITDATA PDU for unacknowledged data transfer. 
FIG. 8 illustrates the format of a SNDCP SN-UNITDATA 55 
PDU used in unacknowledged transmission of GPRS. 
SN-UNITDATA PDU comprises a field N-PDU number 81 
that is a running number progressing throughout the session. 

A mapping between network layer data packets and data 
packets of the protocol layer responsible for the compression 60 
can be generated. In the embodiment herein, a mapping 
between the SNDCP SN-UNITDATA PDU field N-PDU 
number and the RTP sequence number, IP identification and 
the RTP time stamp is shown. When the N-PDU number 
increases by one, values in the RTP sequence number field 65 
316 and IP identification field 335 generally increase by a 
value that is constant throughout the session. Furthermore 
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there are codecs for which the difference between subse- 
quent RTP time stamps is constant. Using a hexadecimal 
representation, for a case where this difference is F0, and the 
increments for RTP sequence number is one and for IP 
identification is 0100, a following mapping is effective: 

N-PDU number=5 

RTP sequence number-16C5 

RTP time stamp =02FFBFEF 

IP identification=E7E6 
N-PDU number-6 

RTP sequence numbered 6C6 

RTP time stamp -02FFC0DF 

IP identification=E8E6 
N-PDU number=7 

RTP sequence number=16C7 

RTP time stamp =02FFC IDF 

IP identification-E9E6 

Though constant increments are utilised herein, mapping 
can be implemented in several other ways, as well. For 
instance, a mapping function between access network layer 
protocol and the network layer protocol header fields can be 
established. Furthermore, depending on the application, 
mapping between any other fields of the access network 
layer protocol and the network layer protocol can be utilised 
as well. The context data in the decompressor comprises the 
information needed for mapping the access network layer 
protocol field to the network layer protocol fields. The 
comparison step of the method presented in FIG. 4 will 
comprise simple validity check of the contents of the access 
network layer field. The context data will preferentially 
remain constant and thus requires no updating (re: step 45). 

For network layer packets, where a possibility for the 
no-change fields to change during a session exists, an 
alternative embodiment shown in FIG. 9 is suggested. The 
embodiment is again presented using the example where the 
transmitting entity is the MS and the receiving entity is the 
SGSN. In connection with the session set-up the state of 
compression is stored in both the MS (SoC c ) and the SGSN 
(step 91) (SoC rf ). When a packet is received from the speech 
codec to be transmitted to the SGSN (step 9), it is checked 
(step 93) whether there is any change in the no-change fields 
of the header to be compressed and the fields in the state of 
compression. If no changes are detected the header is 
compressed as described earlier (step 94) and the com- 
pressed packet is sent to the decompressor (step 95). 
Anyhow, when changes are detected, a new SNDCP func- 
tionality will extract from the new header only the changed 
no-change fields (step 96), update them to the stored state of 
compression (step 97), transmit said values to the SGSN 
(step 98) and update the values to the state of compression 
stored in the SGSN as well (step 98). Transmission of such 
information can be done using acknowledged mode or 
strong error protection. 

In a compression/decompression algorithm any combina- 
tion of these embodiments can be used. Next an example of 
the use of the invented method is given. Table 1 represents 
fields in a full header corresponding to network layer 
protocols IP, UDP, IP. Shaded fields correspond to the fields 
that remain constant throughout the session and white fields 
represent fields that may vary during the session. 
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TABLE 1 



Example of IP, UDP and RTP header 
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Assume that this is the first RTP/IP/UDP header received 
in the SNDCP compressor. The values shown here are in 
hexadecimal format, and there are 4 octets in a row. First 5 
rows (20 octets) represent an IP header. Next two rows are 
octets of an UDP header and last 3 rows represent the RTP 
header, altogether forming a typical RTP/UDP/IP header (40 
bytes). SNDCP compressor shall copy these values and the 
full header is sent to the corresponding SNDCP element. 
Table 2 presents a subsequent header received by the com- 
pressor. 

TABLE 2 



Next IP/UDP/KTP header 
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The fields that differ from the stored values are shaded in 
tables 1 and 2, and comprise 

16-bit identification field of IP header; 

From E7E6 to E8E6 
16-bit header Checksum of IP header: 

From 63DC to 62DC 
16 bit UDP checksum: 

From AF5E to D440 
Sequence number of RTP header: 

From 16C5 to 16C6 
Times tamp of RTP header: 

From 02FFBFEF to 02FFCODF 
Other fields remain the same. Now, according to the 
invention, a following compressed header is generated: 
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TABLE 3 
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Comoressed header 
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The format of the compressed header follows the one 
presented in connection with FIG. 5 and is presented in 
binary form. Since the length of the packet has not changed, 
the 7th bit of the first octet is 0, the marker bit is 0 and in 
this case the rest of the bits in the first octet are zeros. The 
next two octets contain the abbreviated timestamp (CO DF 
in hexadecimal). An SNDCP packet comprising the com- 
pressed header and the RTP payload is sent to the decom- 
pressor. 

The full time-stamp is reproduced from the abbreviated 

20 time-stamp value as described before in connection with 
FIG. 6. The sequence number of RTP header and 16-bit 
identification number of IP header shall be derived using the 
N-PDU number of the SNDCP packet as an offset from the 
last full header. As the decompressor received the first 

25 packet comprising the full header the algorithm made an 
association between RTP sequence number and N-PDU 
number of the SNDCP packet. In this case the sequence 
number would be 16 C5 and the N-PDU number is, say x. 
When the compressed header is sent the SN-UNITDATA 

30 N-PDU number is y, which indicates that the difference 
between the N-PDUs is y-x and that number shall be added 
to the stored sequence number. 

As an example of a network element implementing the 
method described herein a mobile terminal of a mobile 

35 communication system is presented. The structure of the 
mobile terminal according to the invention is by far that of 
a traditional mobile terminal earlier known to a person 
skilled in the art. Referring to FIG. 10, a Central Processing 
Unit 101 controls the blocks responsible for the mobile 

40 station's different functions: a Memory (MEM) 102, a Radio 
Frequency block (RF) 103, a User Interface (UI) 104 and an 
Interface Unit (IU) 105. CPU is typically implemented with 
one or more functionally inter- working microprocessors. 
The memory preferably comprises a ROM (Read Only 

45 Memory), a RAM (Random Access Memory) and is gener- 
ally supplemented with memory supplied with the SIM User 
Identification Module, In accordance with its program, the 
microprocessor uses the RF block 103 for transmitting and 
receiving messages on the radio path. Communication with 

50 the user is managed with by the UI 104, which typically 
comprises a loudspeaker, a display and a keyboard. The 
Interface Unit 105 is the link to a data processing entity, and 
it is controlled by the CPU 101. The data processing entity 
101 may be an integrated data processor or an external data 

55 processing equipment. 

FIG. 10 also illustrates the functional modules of a data 
processing entity TE according to the invention. The termi- 
nal equipment TE may be for example a Personal Computer 
prior known from office environment, or a workstation. TE 

60 may also be an integral part of the MS (e.g. smartphone) 
sharing elements such as UI and CPU with the MS. Vice 
versa, MS may also be integrated in the TE (e.g. card phone). 
It is appreciated, that even though in FIG. 10 two separate 
blocks are shown, no restriction to the configuration is 

65 implied therewith. 

TE substantially comprises an interface unit IU 107 
corresponding to the one in MS, to control the interface to 
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the MS. It also comprises a User Interface UI 108 for 
receiving user commands and outputting information to the 
user, a memory MEM 109 to store applications SW APP 110 
and applications related data, and a processor CPU 111 to 
control the operations of the TE and to carry out the 
application procedures. 

There exists a plurality of methods to connect the mobile 
station MS and the data processing entity, all known to a 
person skilled in the art. One of the methods is to intercon- 
nect the devices through interface units IU comprising wired 
connection, appropriate interconnection interface e.g. a 
serial port, and supplemented with appropriate interfacing 
software in the CPUs controlling the operation of the 
interface units IU. Another method is to use wireless con- 
nection in infrared wavelength range or to use low-power 
radio frequency transceiver units. The new solutions where 
the MS is integrated in the TE also provide a very feasible 
platform to the system according to the invention. 

When a user wants to access a packet data network with 
the TE, on the basis of commands from user input devices 
the processor CPU 111 retrieves from the memory MEM 
109, a packet data access application SW APP 110. The 
application is processed in the CPU 111 in the packet form 
and whenever a need for sending application related infor- 
mation arises, a packet is forwarded to the MS through the 
IU 107. 

In the first embodiment the compression and decompres- 
sion functions are implemented in the SNDCP layer of the 
protocol stack of the mobile terminal. In the embodiment 
shown herein the elements involved with SNDCP function 
are the ones that have here been described in the MS part. 
In uplink direction the MS acts as a compressor and in 
downlink direction the MS acts as a decompressor. 

Values used for the compression and decompression 
operations are stored in the memory 102 of the MS. Com- 
pression is implemented in the central unit 111 and the 
compressed units are forwarded to the RF unit 102 for 
transmitting to the SGSN through the BS. Compressed 
packets from the SGSN are received by the RF unit and 
forwarded to the CPU 111 for decompression. Decom- 
pressed packets are forwarded to the TE through the Inter- 
face Units 105 and 107. 

Although the invention has been shown and described in 
terms of a preferred embodiment, those persons of ordinary 
skill in the art will recognise modifications to the preferred 
embodiment may be made without departure from the scope 
of the invention as claimed below. For example, in future 
GPRS or corresponding services (GPRS derivatives) will be 
implemented to other mobile telecommunication systems as 
well. Third generation WCDMA (Wideband Code Division 
Multiple Access) standard has a structure that is close to 
GPRS, and comprises a L3CE layer, which corresponds to 
SNDCP of GPRS. Such layer for incorporating the func- 
tionalities of the invented is the SNDCF layer of 
CDMA2000. It is possible to apply the invention in fixed 
networks, as well. Thus the possibilities to realize and use 
the invention are limited only by the enclosed claims. 

What is claimed is: 

1. A method for transferring a data packet from a com- 
pressor (MS) to a decompressor (SGSN), said data packet 
including a header with header data fields, a number of the 
header data fields that remain constant during the data 
transfer being stored in the decompressor, the method com- 
prising: 

sending from the compressor and receiving at the decom- 
pressor a data packet comprising information on one or 
more header data fields that vary during the data 
transfer; 
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decompressing the header using the stored header data 
fields and the received information on the one or more 
header data fields that vary during the data transfer; 

comprising 

sending from the compressor and receiving at the 
decompressor a compressed value for a header data 
field, said compressed value identifying the data 
packet in a compression sequence and the com- 
pressed value being formed by taking a first number 
of least significant bits of the header data field; 

maintaining in the decompressor context data compris- 
ing information for relating the received compressed 
value to a corresponding compression sequence, the 
information being updated according to the received 
compressed values; 
using the compressed value and the information of the 

corresponding compression sequence for mapping the 

compressed value into a decompressed header data 

field. 

2. A method according to claim 1, wherein the compres- 
sion sequence comprises a set of successive data packets that 
can be differentiated from each other with the resolution 
provided by the compression value. 

3. A method according to claim 1, wherein the header is 
a RTP/UDP/IP header, the data field is one of the following: 
IP identification, RTP sequence number, RTP time -stamp, 
and the compressed value is a first number of least signifi- 
cant bits of the data field. 

4. A method according to claim 3, wherein the context 
data comprises at least a second number of the most sig- 
nificant bits of the data field. 

5. A method according to claim 1, wherein the compressor 
and the decompressor are network elements of an access 
network to a IP packet data network. 

6. A method according to claim 5, wherein the compressor 
and the decompressor are network elements of a wireless 
access network to a IP packet data network. 

7. A method according to claim 6, wherein the compressor 
and the decompressor are network elements of a mobile 
communication network supporting GPRS. 

8. A method according to claim 7, wherein the compres- 
sion and decompression functionalities are implemented in 
the SNDCP layer of the GPRS. 

9. A method for processing a data packet comprising: 
receiving a data packet comprising an ordinal, said ordinal 
indicating the order of the packet in a series of transmitted 
packets; 

comparing the ordinal of the received packet with an 
earlier stored comparison ordinal; 

initiating, as a response to the difference between the 
ordinal of the received packet and the comparison 
ordinal exceeding a predefined limit, an error function; 

initiating, as a response to the difference between the 
ordinal of the received packet and the comparison 
ordinal being less than a predefined limit, a header 
compression algorithm; 

storing, as a response to the ordinal of the received packet 
being greater than the comparison ordinal and the 
difference between the ordinal of the received packet 
and the comparison ordinal being less than a predefined 
limit, the ordinal of the received packet as the com- 
parison ordinal. 

10. A method according to claim 9, wherein the error 
function comprises discarding the new packet, 

11. A method according to claim 9, wherein the ordinal is 
the time -stamp of a data packet. 
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12. A method according to claim 9, wherein the ordinal is 
the sequence number of a data packet. 

13. An access network element (MS) comprising: 
means for transferring a data packet to a decompressor 

(SGSN) said data packet including a header with 5 
header data fields: 

means for compressing the header by excluding header 

data fields that remain constant during the data 

transfer from transmission; 
means for sending to the decompressor a data packet 10 

comprising information on one or more header data 

fields that vary during the data transfer; 
comprising: 

means for sending a compressed value for a header 
data field associated with identifying the data 35 
packet in a compression sequence, the compressed 
value being formed by taking a first number of 
least significant bits of the header data field. 

14. An access data network element according to the 
claim 13, comprising: 20 

means for receiving a data packet comprising an ordinal, 
said ordinal indicating the order of the packet in a series 
of transmitted packets; 

means for comparing the ordinal of the received packet 25 
with an earlier stored ordinal; 

means for initiating, as a response to the difference 
between the ordinal of the received packet and the 
comparison ordinal exceeding a predefined limit, an 
error function; 30 

means for initiating, as a response to the difference 
between the ordinal of the received packet and the 
comparison ordinal being less than a predefined limit, 
a header compression algorithm; 

means for storing, as a response to the ordinal of the 35 
received packet being greater than the comparison 
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ordinal, the ordinal of the received packet as the 
comparison ordinal. 

15. An access network element (MS) comprising 
means for receiving data packets said data packets includ- 
ing a header with header data fields; 

means for storing header data fields that remain constant 
during the data transfer; 

means for receiving compressed data packets comprising 
information on one or more header data fields that vary 
during the data transfer; 

means for decompressing compressed data packets using 
the stored header data fields and the received informa- 
tion on the one or more header data fields that vary 
during the data transfer; 

comprising: 

means for receiving in a data packet a compressed 
value identifying the data packet in a compression 
sequence, the compressed value being a first number 
of least significant bits of the header data field; 

means for maintaining context data comprising infor- 
mation for relating the received compressed value to 
a corresponding compression sequence, said infor- 
mation being updated according to the received 
compressed values; 

means for using the compressed value and the infor- 
mation of the corresponding compression sequence 
for mapping the compressed value into a header data 
field in a decompressed data packet. 

16. An access data network element according to claim 
13, wherein the element is a mobile terminal of a mobile 
communication network. 

17. An access data network element according to claim 
13, wherein the element is a SGSN of a mobile communi- 
cation network supporting GPRS. 

* * * * * 
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